Native-Language-Based Distributed Computing Across Network and Filesystem Boundaries BLENDING THE PORTABILITY OF JAVA WITH COMPUTATIONAL ENGINES WRITTEN IN NATIVE LANGUAGES TO ACHIEVE CROSS-NETWORK, HETEROGENEOUS, CONCURRENT COMPUTING

This paper discusses how the aspects unique to the Java programming language can be combined with complementary and unique aspects of other languages such as C and Fortran. This combining of the strong features of Java, such as portability and platform independence, with packages and legacy codes written in traditional languages such as C and Fortran results in a program blend which exhibits portability and speed not realizable by any of these languages individually. One area where this con uence of previously-disparate language features has strong potential is in the area of distributed, concurrent computing over heterogeneous platforms and across local network and lesystem boundaries | the setting addressed within this paper. Also addressed in this paper are the pivotal aspects of the Java bytecode representation of a class object which makes the porting of shared libraries across network boundaries, lesystems, and architectures possible. 1 Blending Existing and Evolving Technologies As a programming language, several e ective language-level features of Java lend to it being a highly-portable language. Many of these features are supported by the static representation of a Java program's executable state | its bytecode representation[8]. This encapsulation of a programming unit into a concise and compact, system independent form goes a long way toward Java's programming-side goal of \write once, run anywhere," where a programmer can write and compile a program on any platform and run the compiled version of the bytecode on any other platform. However, the advancement in a Java program's portability is often at the cost of executional speed. While there are many ongoing projects which aim to promote Java as a high-performance language ([1] and [7] for example), its lacking execution speed is arguably a most signi cant obstacle which must be overcome. Another factor which limits any new programming language from wide acceptance by the scienti c community is the large amount of legacy codes in existence. \Legacy" code refers to scienti c programs already written in languages such as C, C++, and/or Fortran. Many scienti c packages and communication libraries exist as highly-optimized, system-dependent codes or libraries written in Fortran, C, or variants thereof (such as HPF[10] or HPC++[3] for example). Switching to a new programming language would possibly mean abandoning these familiar and established packages for less familiar and perhaps less-stable variants written in the newer language. Table 1 below is given to support to two distinct issues: 1. The scienti c community's reluctance to accept Java as a high-performance language for lack of speed, and 2. the potential for using Java as a front-end (a wrapper) to legacy codes and packages. Standalone Java-based Program (w/ JIT) Standalone C Implementation (w/ Compiler Optimization) Java-wrapped LINPACK engine(w/ JIT) C-wrapped LINPACK engine (w/ optimized C wrapper) 437.9 (103.4) 84.7 (24.4) 42.7 (41.2) 17.0 (16.9) Table 1: Benchmarks (in seconds) under various implementations for the computation of multiplying two 500x500 matrices on a single Sun Sparc20 workstation. The quantities in parenthesis represent the best-e ort compiler/JIT optimizations of the respective implementations. The data in Table 1 shows executional times for the multiplication of two 500 500 matrices under various implementations. The rst column shows a standalone Java implementation of the task at hand using the 1.1.4 release of the Java Development Kit (JDK); the second column a standalone C implementation. The last two columns show implementations of the matrix multiplication task which mix languages and utilize the well-established numerical codes found in the Fortran-based LINPACK blas[2]. The third column shows a Java-based wrapper which utilizes the LINPACK ddot subroutine to perform the columnrow dot products of the matrix multiplication. The nal column shows an equivalent implementation using C as the wrapper to the LINPACK ddot subroutine. Times given in parenthesis are best-e ort compiler optimizations of the implementations. While Table 1 lends strong support to the viability for using Java as a wrapper to legacy codes, it says nothing to the additional levels of portability Basic linear algebra subroutines.